連載 144 ワークステーションのおと 坂下秀 ThinkPad 570 のその後 先月号で、 1 年ほど使っていた ThinkPad 240 の 液品ディスプレイの調子が悪くなったので、旧モデルの ThinkPad 570 を購入し、電子メールのやりとりや原稿 のに使っていると書きました。 IBM のサービスを利 用して、日本言部己列のキーポードを英言改」のものに交換 したことにも触れました。 この記事を読んだ知人から、 「キーポードの交換なんか、自分でやったらええがな。 5 月号の特集に書いてあったやん」 と言われました。しつは、私も自分で交換しようと思った のですか断念したのです。 自分でキーポードを交換するには、 ThinkPad 570 の 構造を孑当屋しておく必要があります。そこで、日本 IBM の Web サイトにあるサポート関連のページで情報を 探したところ、「 PC 関連マニュアル」というべージ 1 に ThinkPad 570 の保守マニュアルがありました (PDF ファイルです ) 。読んでみると、分解の方法や、キーポー ドの耳せトし方などが丁寧に書かれています。 「ふんふん、これやったらできそうやな」 さらにあちこちを読んでいると、「ねじの注意事項」と いう一節があり、次のように書かれていました。 「このコンピューターは、以、下ク罸生をもっ牛朱なナイロ 一回しか使えない」 締めるにはさらに力を加える必要がある。 ならない。 衝撃または振重励ミ加わる場合であっても、簡単に緩くは ・密着した接続をイ寺する。 ン・コーティングねしを使用しています。 UNIX MAGAZINE 2000.11 1 http://www.ibm. CO. jp/pc/home/manual/thinkpad. html 「え、 1 回しか使われへんの ? そんなもったいないことせ また使うたらええがな」 ところが、このネジは再利用できないようです。マニュ アルには、 んと、 Emacs Lisp は、 Lisp という言語の 1 つの方言です。 というファイルに、 Emacs Lisp て当します。 は C:*My Documents にしています ) に置いた . emacs Meadow の設定は、ホーム・ディレクトリ ( 私の場合 570 (Windows 98 ) です。 します。使う PC は、もちろん上で書いた ThinkPad ろまで説明しました。今月は、日本謌周連の設定から解説 前回は、 Meadow をインストールして起動させるとこ Meadow の設定 したのです。 換することは諦め、 IBM か提供する交換サーピスを利用 ない」をモットーにしているので、自分でキーポードを交 かの人がぶじに渡り終えたのを見届けてからでないと渡ら 私は、 PC については「たとえ難失でできた橋でも、ほ 「あかんなぁ・・ けれはならないようです。 念ながら、、未なナイロン・コーティングねし " を外さな しかし、キーポードを交換する手順を読んでみると、残 んとちゃうの」 、特殊なナイロン・コーティングねし " 、外さんでもええ 「もしかして、キーポードを分解するだけやったら、この ときは、新しい専用のネジが必要なのです。 と書かれています。つまり、いったん分解して組み立てる します」 「ねしを付けるよう指示されたら、必す新しいねしを使用 115
連載 Java Advisor— 呼び出す可能生がある。再帰ロックのない言語では、ロッ グラムなら、通常は m2 が。 bj に再帰ロックをかけること クをかけずに自分自身を再帰的に呼び出してイ乍業をおこな ができる。性能が多明生になることを除けば、ほかに被 うメソッドと、ロックをかけてからもう 1 つのメソッド 害をおよは、さない優れた実装である。だからといって、 も を呼び出すメソッドを作成しなけれはならない。だが、こ う面倒なことは考えなくてもいいというわけではない。も のメソッドはこうした煩わしさを解消するだけで、そオび丿、 う 1 つのガ去は、 m2 の一兼コメント ( もちろん書いてい 上作業を合理化するわけではない。 、 obj がロックされている場合にのみ呼 ると思うが ) に、 こうしたロック順の条件を石忍する正しいガ去は、仕様 び出される " という前提条件を追加することだ。 m2 の呼 を拡張することだ。い期メソッドに次の条件を追加してみ 出しのたびにこのプロバティを石忍すれば、その前提条件 をもとに、 m2 の変数へのアクセスがロックの条件を満た しているかどうか石忍できる。 / * REQUIRES maxLock(curThread) く = this * / public void synchronized meth() { 再帰ロックがあるのに、なぜこのような煩わしいイ : 様が なくならないのだろうか。デッドロックのせいである。私 が知るかぎり、デッドロックを回避するには、システム この制約を、メソッド meth を呼び出すたびに確かめ のすべてのロックに順番を設疋し、スレッドがそれぞれ なけれはならない。なんとも気か重くなるが、私の知るか 昇順でロックをかけるようにするしかない。ロ囎辰替の例 ぎり、すべてを鮹夬する見込みがあるのはこのガ去だけで でいえは、 BankAccount を口座番号順に並べることにな ある。 る。振替えをおこなうには、口座を正しい順番でロックし 私たちは、実彳・丁時のロック順違反の検出を含め、 JVM なければならない。 Customer も定義する場合は、 Bank- を実装する C のコードを記述する際にこうしたテクニッ Account よりも順番の早いロックを定義することになる クを活用している。 Java フログラムにこのようなコメン だろう。 Customer と BankAccount を両方ともロック トを付ける時間があるなら、ゆくゆくはロックの信に従 するスレッドは、ます Customer をロックしなければな ってプログラムを本館正するツールか元成するだろう。私は らない。 Greg Ne 00 らと協力して、こうし Modula-3 のツー ロックを安全にかけるには、ロックをかける ( メソッド ルに 4 年間取り組んでいる。難しい譏題だが、作業は著し を実行する ) スレッドが、順番の遅いロックをすでにかけ こうしたテ い進展をみせている。この研究グループでは、 ていないか石忍しなけれは・ならない。再帰ロックは例外と クニックを Java 言語に樹直しようとしている。和次の みなすことかて、きる。スレッドがあるオプジェクトをロッ 大きな並行 Java プログラムに取り組むまでに、彼らの作 クし、次にロック順の遅いオプジェクトをロックして、さ 業か完了していてほしいものた : らに最初のオプジェクトに再帰ロックをかけても、デッド ロックのおそれはない。だが、間題は何も鮹夬されない。 ・ David Detlefs Sun Microsystems 不幵究所のスタッフ・エンジニア。 JVM の そのためには、ロックか再帰かどうかを突き止めなけれは 新勺な実支術に取り組んでいる。 ならないからだ。 「 Concurrent Coffee 」 メソッドがオプジェクトをロックする際、カレントス Performance Computing 1999 年 7 月号より レッドはそのオプジェクトをすでにロックしているかもし ◎ 1999 , Performance Computing (). S. A. ) れないし、していないかもしれない。オプジェクトがロッ クされていない場合は、デッドロックを防ぐために、ス レッドがロック順の遅いオプジェクトをロックしていな いカ蔀忍しなけれはならない。オプジェクトがすでにロッ クされていて、それを石忍できるなら、再帰ロックにでき ることは何もない。だからといって、再帰ロックか役に立 たないわけではない。同期メソッドは自分自身を再帰的に 114 UNIX MAGAZINE 2000.11
並行にアクセスされるフィールドや static な変数には、 連載 Java Advisor— するためのロックとしては、多くの場合オプジェクトカ硬 込みのためにイ矍しなければならない。フィールドをイ ない。つまり、フィールドまたは変数を、言翹 ( りまたは書 そのフィールドをイするロックカ甘旨定できなければなら / * PROTECT a,b,c BY this * / private int a, b, class SomeC1ass { われる。 C ; このコメントは、 a 、 b 、 c フィールドの言翹りまたは書 に Customer をロックした例を憶えているだろうか。そ イされるわけではない。顧客の口座にアクセスするため オプジェクトをロックしても、すべてのフィールドが らないことを意味する。 込みをおこなうには、 SomeClass をロックしなければな こで、 Customer を次のように定義する。 こうしたコメントを付けることや、コードを入念に見直 accounts [i] BY this * / / * FORALL i : PROTECT a11 fields BankAccount ロ accounts ; / * PROTECT name , PIN BY this * / private int PIN; String name ; class Customer { of る。フィールドや変数にアクセスする場合は、次のように すことを厭わなけれは、競合状態を回避できる見込みがあ 間わなければならない。 UNIX MAGAZINE 2000 ユ 1 る別のメソッド (m2) を呼び出すことがある。 Java プロ 取得し、ある操作をおこなうために。 bj のロックを要求す るメソッド ( ml ) があるオプジェクト ( 。 bj ) のロックを ドは必要なロックをローカルでかけるからだ。しかし、あ なる。多くの場合、その答は明白である。アクセスメソッ この最後の間いが、コメント規則の第 2 段階への糸口と かけているだろうか。 ・あるとしたら、アクセスするスレッドは必要なロックを ・ないとしたら、それは確実だろうか。 あるだろうか。 ・このフィールドや変数が、並行にアクセスされることは SC 翡 好評発売中 ! Ja a フログラミング・ノート 国際化と 日本語処理 CAFE BABE u N ー X ava フ恤グラミング・ノート 国際化と日本語処理 SC ・風間一洋著 ・ A5 判、 312 ページ ・旧 B N 4-7561-3481-5 ・本体 3 , 000 円十税 Java による日本語処理、さらには国際化 プログラミングに必須の知識を数多くの サンカいプログラムを示しながら平易に 解説する。真の意味での "write Once, Run Anywhere" を目指すプログラマー 目次から に最適の 1 冊。 1 章 2 章 付録 12 章 1 1 章 10 章 9 章 8 章 7 章 6 章 5 章 4 章 3 章 Java はどんな言語か 国際化と地域化 ユーロ通貨記号への対応 工ンコーティング名一覧 / タイムゾー冽 D 一覧 / Unicode プロック / ロケール一覧 / 文字の表示 インブットメソッド テキストの境界解析 文字列の比較 フォーマット出力と解析 リソース / ヾンドル タイムゾーン 工ンコーディング ロケー丿レ Unicode 株式会社アスキー 113 電話 (08) 535 ト 8194 出版営業部 〒 1 5 1 ー 8024 東京都渋谷区代々木 4 ー 33 ー 1 0